home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1998 January: Mac OS SDK / Dev.CD Jan 98 SDK1.toast / Development Kits (Disc 1) / Apple Game Sprockets / NetSprocket 1.0.3 / NetSprocket Release Notes next >
Encoding:
Text File  |  1996-12-13  |  7.5 KB  |  173 lines  |  [TEXT/CWIE]

  1. NetSprocket 1.0.3
  2. Release Notes
  3. ---------------
  4.  
  5. Please report all bugs to sprockets@adr.apple.com!
  6.  
  7.  
  8. What's New?
  9. -----------
  10.  
  11. NetSprocket 1.0.3 is a bug-fix for NetSprocket 1.0, and contains one new 
  12. feature.
  13.  
  14. Note that NetSprocket 68K has been delayed until the CFM68K problem has
  15. been fixed.  For more info on the CFM68K problem, see www.apple.com.
  16.  
  17. NetSprocket 1.0.2 was an internal-only release.
  18.  
  19. Bugs fixed:
  20.  
  21. 1.  If the user chose not to play on the host machine, NetSprocket could
  22.     crash under certain circumstances.  Note that your game needs to be 
  23.     able to handle having a "headless server," or it needs to disallow
  24.     a blank username.  Being a headless server means that you should
  25.     never call NSpMessage_Send.
  26.  
  27. 2.    NetSprocket had been linking OT libraries with normal, as opposed to
  28.     weak linkage.  This would cause your app to fail at init time if the
  29.     user had NetSprocket, but not OT, installed.
  30.     
  31. 3.    Async message handlers were not being called all the time.  Some 
  32.     messages would slip through, and your handler would not be notified.
  33.     
  34. 4.    There have been several improvements to the HI, including alerts that
  35.     tell the user when the username is empty when an improperly formed
  36.     IP address was entered, and when a DNS name couldn't be resolved.
  37.     
  38. 5.    The NetSprocket.h header had an incorrect parameter type for 
  39.     NspProtocolList_GetCount().  The first parameter should be of type
  40.     NSpProtocolListReference, not NSpProtocolReference.  This change
  41.     has no code-level effect (they are both 32 bit unsigned ints).
  42.     
  43. 6.    NetSprocket would not release an IP port immediately after a game
  44.     ended.  This would cause the user to have to select a new port
  45.     if he hosted a game, quit, and then immediately hosted another game.
  46.     The delay was 4 minutes, which is actually part of the RFC for TCP/IP.
  47.     However, we have changed NetSprocket so that the port is released
  48.     immediately.
  49.     
  50. 7.    Fixed the crash in EnableAdvertising.  The function now works as expected.
  51.  
  52. 8.    Fixed a memory leak that would cause memory to be allocated and not
  53.     released if you hosted or joined repeated games.  The memory is now
  54.     allocated once each time your app is launched.  Note that, since
  55.     NetSprocket uses OT's memory allocators, its memory comes out of the 
  56.     System Heap.  Also, while it may SEEM that memory is not being freed,
  57.     that may be misleading since OT does its memory cleanup when NetSprocket
  58.     is unloaded.
  59.     
  60. 9.    Exposed the NSpGetVersion function.  This returns a NumVersion type,
  61.     the same as what you find in the 'vers' resource.
  62.     
  63. 10.    Exposed the NSpGame_GetInfo function.  This had been unexported because
  64.     of some issues around the information you get when you call it from a 
  65.     joiner.  You don't get the correct max players, and you don't get the
  66.     correct game name when you call this from a joiner.  The fix has been
  67.     deferred to another release, since it's not a critical component.
  68.     
  69. Feature:
  70.  
  71.     The way IP ports are handled has changed a little.  If you don't
  72.     add an IP protocol ref to the protocol list you pass to
  73.     NSpDoModalHostDialog, NetSprocket will suggest a default IP port
  74.     to the user, based on the value of inGameID, passed to NSpInitialize.
  75.     NetSprocket will also put this as the default value in the port
  76.     for the join dialog.  The default port is calculated by:
  77.     
  78.     (creatorType % (32760 - 1024)) + 1024;
  79.     
  80.     What we recommend you do is not add an IP protocol ref to your
  81.     protocol list, and just let NetSprocket pick the right port for
  82.     you.  If you do want to use the IP protocol ref, we recommend
  83.     that you use this as your default port, since it is what will
  84.     be displayed for the IP panel in the join dialog.  In both cases,
  85.     the user can override the suggested port.
  86.     
  87.     As part of this change, the Join dialog changed slightly.  The port
  88.     is now set in a separate field.
  89.  
  90.  
  91. Release Components
  92. ------------------
  93.  
  94. NetSprocket Release Notes                - this file
  95. NetSprocket.h                             - the header file to compile with.
  96. NetSprocketLib                           - release version of the library
  97. NetSprocketDebugLib                       - debugging version of the library
  98. NetSprocketTest                           - test program
  99. NetSprocketTest.ยต                        - Code Warrior 9 project to build test
  100. NetSprocketTest Sources                    - sources for test program
  101.  
  102. Note:  NetSprocketTest uses Metrowerks' PowerPlant, and requires CW8 or later
  103. to build.
  104.  
  105. WARNING: don't place both the debugging and non-debugging versions of the
  106. library in the search path or you will not be sure which version you will be
  107. using.
  108.  
  109. Dependencies
  110. ------------
  111.  
  112. NetSprocket requires OpenTransport version 1.1 or later.  1.1 is the version
  113. that is installed by the System 7.5 Update 2.0, or the System 7.5.3 installer.
  114.  
  115. NetSprocket requires the latest Universal Headers -- version 2.1.2 or later.
  116. You can find them on E.T.O. #20, the MacOS SDK CD-ROMs, Apple's web-site, or
  117. a number of other locations.
  118.  
  119. Compatability with Prereleases
  120. ------------------------------
  121.  
  122. NetSprocket 1.0.3 is fully compatible with all previous releases.
  123.  
  124. Getting the Most out of NetSprocket
  125. -----------------------------------
  126.  
  127. To get the optimal performance out of NetSprocket, design your game to send
  128. "Normal" messages that contain less than 550 bytes of data.  This allows
  129. NetSprocket to use datagram-level delivery for both TCP/IP and AppleTalk. 
  130. Using "Registered" messages can cause a 2-50% network performance degradation,
  131. depending on a number of factors, including network bandwith, utilization,
  132. message size, and send frequency.
  133.  
  134. All messages, except ones sent from a player to himself, are sent through the
  135. host.  Therefore, the host is one "hop" from any other player, and two non-host
  136. players are always two "hops" apart.
  137.  
  138. Sending a message to a group is not as efficient as sending to everyone in the
  139. game, or to a single player.  It is usually more efficient than sending to each
  140. individual in the group separately.
  141.  
  142. You CAN NOT send messages at VBL (or any other interrupt) time with NetSprocket
  143. 1.0.  You should schedule a deferred system task, or just wait until system
  144. task time before sending.  You CAN however, call NSpMessage_Get at interrupt
  145. time.  We generally recommend against all interrupt-time calls to the Game
  146. Sprockets.
  147.  
  148. The number of players in a NetSprocket game is limited only by memory (and
  149. networking resources, such as available ports).  If you exepect to handle lots
  150. of players (14+), you need to make sure you give NetSprocket sufficient memory
  151. and queue elements when you initialize it.  If you get send failed or memory
  152. error message from NetSprocket, try giving it more memory.
  153.  
  154. If you have a situation where your game has players whose network throughput is
  155. greatly disparate, you need to make sure you don't choke the slow person.  For
  156. example, if you have 4 players on AppleTalk over Ethernet, and you have a fifth
  157. player join the game over a 28.8k PPP connection, and your fast machines are
  158. sending messages 30 times a second each, you're going to quickly gag the
  159. newcomer with too much data, and the host will simply not be able to deliver
  160. messages as quickly as you generate them.  The newcomer will be disconnected
  161. after approximately 20 messages have been queued up, waiting for flow control
  162. to lift before delivering them.  You can avoid this type of problem by
  163. throttling down your game's send rate to allow the newcomer to participate. 
  164. You can also avoid it by sending "Junk" messages instead of Normal.
  165.  
  166. NetSprocket 1.0 does not implement Round-Trip-Time or throughput functions,
  167. though the next release will.  You can implement your own RTT and thruput
  168. functions on top of the NetSprocket API yourself, though.
  169.  
  170. Known Bugs
  171. ----------
  172.  
  173. Host renegotiation does not work.